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1    INTRODUCTION. 


Experimental  Path  Pascal  is  designed  to  investigate  the  benefits  and 
problems  that  arise  when  path  expressions  are  combined  with  a  language  to  pro- 
vide a  system  programming  tool.  Instead  of  altering  the  Pascal  language  exten- 
sively, a  minimal  number  of  features  was  added  such  that  Pascal  programs  still 
compile  and  execute.  The  language  can  be  used  as  an  instructional  tool  or  for 
the  construction  of  example  system  programs.  This  manual  describes  the  Path 
Pascal  features  and  the  implementation  on  the  Cyber  and  PDP11. 

Path  expressions  were  introduced  as  a  technique  for  specifying  process 
synchronization  by  [Campbell  and  Habermann,  74] ,  and  further  discussed  by 
[Habermann,  75],  [Lauer  and  Campbell,  75],  [Flon  and  Habermann,  76],  [Andler, 
79]  and  [Campbell,  77].  Variations  of  the  path  expression  idea  have  been  pro- 
posed by  [ONERA  CERT,  77]  and  notations  that  are  similar  to  paths  that  model 
system  behavior  have  been  developed  independently  by  [Shaw,  77]  and  [Riddle, 
76].  A  specification  language  has  also  been  designed  [Lauer  and  Shields,  78] 
based  upon  the  use  of  a  path  expression  notation. 

Path  Pascal  is  based  on  the  P4  subset  of  Pascal  [Ammann,  et  al,  76] 
(see  Appendix  F  for  a  summary  of  the  P4  subset).  The  Path  Pascal  compiler  is 
written  in  Pascal  P4  and  will  accept  any  Pascal  P4  program  that  does  not  use 
Path  Pascal  reserved  words  as  identifiers.  The  modifications  to  Pascal 
involved  the  addition  of  an  encapsulation  mechanism  (see  chapter  3),  Open  Path 
expressions  [Campbell,  77]  (see  chapter  4),  and  processes  (see  chapter  5). 
Open  Paths  are  integrated  with  the  encapsulation  mechanism  to  enforce  a 
strict  discipline  upon  the  programmer  describing  shared  data  objects.  All 
access  to  encapsulated  data  is  performed  by  operations  synchronized  by  Open 
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Paths.  A  process  invoking  such  an  operation  may  only  execute  the  operation  if 
permitted  to  by  the  Open  Path  expression  associated  with  the  shared  data 
object. 

The  following  sections  describe  Path  Pascal  in  more  detail.  Motiva- 
tions for  the  design  of  Path  Pascal  are  discussed  further  in  [Miller,  78].  A 
description  of  Pascal  can  be  found  in  the  Pascal  Report  [Jensen  and  Wirth, 
75].  The  additional  Path  Pascal  syntax  is  listed  in  Appendix  A.  Appendix  B 
contains  the  Path  Pascal  compiler  error  messages,  and  the  Path  Pascal  P  code 
interpreter  control  options,  constants,  and  error  messages.  Appendix  C 
describes  the  semantics  of  Open  Path  expressions  in  terms  of  P  and  V  opera- 
tions. Appendix  D  contains  several  sample  programs.  Appendix  E  describes  the 
changes  that  have  been  made  to  the  intermediate  code  (P-Code)  for  the  addi- 
tional Path  Pascal  constructs. 
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2    DATA  ENCAPSULATION. 

Path  Pascal  Includes  an  encapsulation  mechanism  called  an  object. 
Objects  allow  useful  user-defined  data  structues  to  be  programmed  but  are  not 
intended  as  a  general  solution  to  abstract  data  types.  They  permit  synchroni- 
zation to  be  associated  with  shared  data  and  are  implemented  as  an  extension 
of  the  Pascal  structured  type  facility. 

An  object  provides  controlled  access  to  a  data  structure  and  consists 
of  a  declaration  of  the  data  structure  together  with  a  set  of  operations  which 
access  the  values  of  that  structure.  Path  Pascal  allows  algorithms  to  be 
expressed  in  the  form  of  routines  (procedures,  functions,  and  processes). 
Operations  are  constructed  from  routines  (Thus,  operations  may  be  defined  in 
terms  of  calls  upon  additional  routines).  Objects  and  their  operations  iso- 
late the  internal  data  representation  of  values  of  the  object  from  the  rest  of 
a  program.  This  isolation  is  enforced  by  restricting  manipulations  of  the 
data  structure  of  an  object  to  the  textual  unit  comprising  the  object.  Opera- 
tions are  specified  by  prefixing  the  declaration  of  a  routine  with  the 
reserved  word  'ENTRY'.  Since  Path  Pascal  permits  concurrent  asynchronous 
processes,  several  processes  can  try  to  access  an  object  at  the  same  time.  It 
is  necessary  therefore  to  synchronize  and  coordinate  the  execution  of  these 
operations.  This  synchronization  is  specified  for  each  object  by  an  Open  Path 
Expression. 

BNF  for  an  object  is  shown  below: 
<object  type>  ::=  OBJECT  <object  block>  END; 
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<object  block>  ::  = 

<path  declaration  part> 

<constant  definition  part> 

<type  definition  part> 

<object  variable  declaration  part> 

<operation  declaration  part> 

<initialization  part> 


An  example  of  an  object  is: 


CONST 

nbuf  ■  5; 
OBJECT 

PATH  nbuf:  (1:  (fill);  1:  (empty)  )  END; 
TYPE 

buffsize  ■  L.nbuf; 

inbuff  »  ARRAY [buffsize]  OF  CHAR; 
VAR 

buf:  inbuff; 

nextspot:  ring; 
ENTRY  PROCEDURE  fill(inchar:  CHAR); 

BEGIN  inbuff  [nextspot. inpointer]  :=  inchar  END; 
ENTRY  FUNCTION  empty:  CHAR; 

BEGIN  empty  :=  inbuff  [nextspot. outpointer]  END; 
END; 


The  example  object  implements  a  five  character  ring-buffer  using  an 
array  of  characters  'inbuf  and  a  pointer  scheme  whose  algorithm  and  values 
are  determined  by  the  operations  'inpointer'  and  'outpointer'  on  the  variable 
'nextspot'  of  type  'ring'  (an  object  declared  in  an  enclosing  scope).  The 
example  object  has  an  internal  data  representation  constructed  from  'inbuf 
and  'nextspot'  and  the  values  of  the  object  are  changed  by  executions  of  the 
operations  'fill'  and  'empty'.  A  path  expression  synchronizes  executions  of 
the  operations  so  that  the  object  may  be  shared  between  two  communicating 
processes. 
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2. 1    Scope. 

An  object  defines  a  block,  possibly  containing  local  constants,  types, 
variables,  routines,  and  the  object's  operations.  The  scope  of  all  the  local 
identifiers  except  the  names  of  the  operations  obeys  the  standard  rules  of 
Pascal.  The  operation's  identifiers  are  exported  to  the  scope  of  the  block,  in 
which  the  object  is  declared  and  may  be  invoked  within  that  scope.  Thus,  the 
data  structures  within  the  object  may  only  be  manipulated  externally  by  the 
execution  of  an  operation.  In  the  buffer  example  above,  neither  'nextspot' 
nor  'inbuff  are  defined  external  to  the  block  of  the  object. 


2.2   Declaration  of  Objects. 

Like  other  Pascal  structured  types,  objects  can  be  defined  and  named 
in  a  type  declaration,  or  can  appear  directly  in  a  variable  declaration.  An 
examples  of  a  type  declaration  is 


TYPE   ring  =  OBJECT 

PATh  inpointer  ,  outpointer  END; 
VAR  inp,  outp:  buff size; 
ENTRY  FUNCTION  inpointer:  buff size; 
BEGIN  inp  :=  inp  MOD  nbuf  +  1; 

inpointer  :=  inp 
END; 
ENTRY  FUNCTION  outpointer:  buffsize; 
BEGIN  outp  :=  outp  MOD  nbuf  +  1; 

outpointer  :=  outp 
END; 
INIT; 

BEGIN  inp  :=  0;  outp  :=  0  END; 
END; 


and  an  example  of  a  variable  declaration  is 
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VAR   id:  OBJECT 

PATH  1:  (get)  END; 

VAR  count:  integer; 

ENTRY  FUNCTION  get:  integer; 

BEGIN  count  :-  count  +  1;  get   :■  count  END; 
INIT; 

BEGIN  count  :-  0  END; 
END; 


Declaring  an  object  in  a  type  declaration  allows  its   associated  name   to  be 
used  to  declare  variables  of  that  type.  An  example  of  this  is 

VAR  pointers:  ring; 
Each  variable  that  is  declared  as  an  object  creates  an  instance  of  that  object 
which  possesses  its  own  independent  1)  block  of  storage,  2)  copy  of  the 
object's  operations,  and  3)  synchronization  information  to  control  the  order 
in  which  its  copy  of  the  operations  are  executed.  These  three  items  are 
described,  respectively,  in  an  object's  1)  object  variable  declaration  part, 
2)  operation  part,  and  3)  path  declaration  part.  Thus,  successive  executions 
of  the  operation  'get'  on  the  variable  'id'  above  will  return  the  integer 
values  1,  2,  3,  and  so  on. 

2 . 3   Structured  Types  Containing  Objects. 

Structured  types  containing  objects  may  be  declared  and  objects  may  be 
nested  within  each  other.  Recursive  object  definitions  cause  a  compile  time 
error.  Two  examples  of  structured  types  containing  objects  are 

TYPE  rec:  RECORD 

fl:  ring; 

f2:  OBJECT  ...  END; 
f3:  integer 
END; 

and 


Page  7 


VAR     a:  array  [1  ..  20]  of  ring; 
r:  rec; 


2.4  Pointers  to  Objects. 

Pointers  to  objects  or  records  containing  objects  may  be  declared. 
Examples  of  such  pointer  declarations  are 

VAR  ptrring:  **  ring; 
ptrrec:  "  rec; 

Dynamic  variables  may  be  created  from  type  declarations  of  objects  or  records 
containing  objects  by  executing  the  standard  procedure  NEW  with  the  appropri- 
ate pointer  argument.   Examples  of  the  creation  of  dynamic  variables  are 

NEW  (ptrring); 
NEW  (ptrrec); 

2.5  Path  Declaration  Part. 

The  path  declaration  part  consists  of  a  single  Open  Path  expression 
which  serves  two  purposes.  It  specifies  the  synchronization  constraints  on  the 
object's  operations.  These  constraints  must  be  met  before  access  to  the 
object's  data  structure  is  allowed.  The  path  also  declares  the  operation  iden- 
tifiers which  are  known  outside  the  scope  of  the  object.  The  compiler  checks 
each  path  to  ensure  that  each  operation  id  appears  exactly  once. 

A  path  declaration  part  (shown  below  in  BNF)  can  be  either  empty  or 
may  contain  an  open  path: 


<path  declaration  part>   ::= 
<empty>  | 
<open  path> 
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Examples  of  paths  are: 

PATH  nbuf:  (  l:(£ill);  1:  (empty)  )  END; 
PATH  inpointer,  outpointer  END; 

Open  Path  expressions  are  detailed  in  chapter  4. 

2.6  Type  Definition  Part. 

Any  type  definitions  may  be  declared  in  the  type  definition  part 
including  new  object  type  definitions.  It  is  therefore  possible  to  nest 
objects  in  Path  Pascal.  Type  definitions  may  use  simpler  type  definitions 
declared  global  to  the  object. 

2 . 7  Variable  Declaration  Part. 

The  object  variable  declaration  part  declares  the  local  data  structure 
of  the  object.  This  local  data  structure  can  contain  objects  and  may  use  type 
definitions  declared  global  to  the  object. 


<object  variable  declaration  part>   ::= 
VAR  <variable  declaration> 

{;  <variable  declaration>}    ; 


An  example  of  an  object  variable  declaration  part  is; 


VAR 

buf:  inbuff; 
nextspot:  ring; 


This  example  is  taken  from  an  earlier  example. 
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2.8   Operation  Declaration  Part. 

The  operation  declaration  part  specifies  the  routines  and  operations 
that  can  be  performed  on  the  local  data  structure  of  the  object.  Operations 
may  be  invoked  outside  of  the  object  but  other  routines  are  strictly  local  and 
can  only  be  invoked  by  operations  or  the  initialization  part.  Operations  are 
distinguished  from  routines  by  prefixing  them  with  the  reserved  word  'ENTRY'. 
Each  operation  identifier  must  appear  in  the  object's  path  expression  in  order 
to  be  synchronized  and  exported. 

<operation  declaration  part  >   ::=  {  <operation  part>) 

<operation  part>   ::= 
<operation>  | 
<routine> 

<routine>   ::= 

<procedure  declaration>  | 
<function  declaration>  | 
<process  declaration> 

<operation>   : : = 

ENTRY  <routine> 

An  example  of  operation  is: 

ENTRY  FUNCTION  outpointer:  buffsize; 
BEGIN 

outp  :=  outp  MOD  nbuf  +  1; 
outpointer  :=  outp 
END;   (*outpointer*) 

Operations  and  routines  within  an  object  can  invoke  other  operations 
and  routines  declared  within  the  object  as  long  as  these  invoked  operations 
and  routines  are  declared  first  or  declared  to  be  forward.  Synchronization  is 
applied  as  usual  for  an  invoked  operation. 

An  operation  can  be  invoked  from  within  its  object  as   if   it   were   a 


Page  10 
routine.  This  differs  from  the  notation  used  when  it  is  invoked  from  outside 
its  object,  as  is  illustrated  in  the  following  example: 

1  PROGRAM  test  (  ...  ); 

2  VAR   ob:  OBJECT 

3  PATH  a,  b  END; 

4  VAR  . .  . 

5  ENTRY  PROCEDURE  a; 

6  BEGIN  ...  END; 

7  ENTRY  PROCEDURE  b; 

8  BEGIN  ...  a;  ...  END; 

9  PROCEDURE  c; 

10  BEGIN  ...  b;  ...  END; 

11  END  (*  ob  *); 

12  BEGIN  ...  ob.a;  ...  END. 


The  references  in  lines  8  and  10  only  specify  the  entry  operation  name,   while 
the  reference  in  line  12  must  use  the  dot  notation. 

Procedures  and  functions  defined  within  an  object  may  be  recursive. 
However,  recursive  entry  procedures  or  entry  functions  may  result  in  deadlock. 
Processes  are  described  in  detail  in  chapter  5. 

2.9   Initialization  Part. 

The  Initialization  part  is  an  optional  block  that  is  used  to  initial- 
ize an  object's  local  data  structure  and  create  any  local  processes.  The 
block  is  Invoked  whenever  a  new  instance  of  that  object  is  declared  or  dynami- 
cally created.  Labels,  constants,  types,  variables,  and  routines  can  be 
declared  within  the  initialization  block.  Any  identifiers  available  inside 
the  object  are  automatically  inherited  and  can  be  freely  accessed  or  invoked. 
Operations  of  the  object  may  be  invoked  as  routines. 
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<initialization  part> 
<emp  ty> 
INIT;  <block> 


Examples  of  initializations  are: 


INIT; 
BEGIN 

inp  :=  0;   outp   :=  0 

END; 

INIT; 

VAR  i:  INTEGER; 

PROCEDURE  q  (  j:  INTEGER  );  BEGIN  ...  END; 

BEGIN 

FOR  i  :=  1  TO  10  DO  q; 
END; 


For  object  variables  that  contain  further  objects  in  their  local  data  struc- 
ture, the  init  blocks  of  the  objects  in  the  data  structure  are  executed  first. 
The  use  within  an  init  block  of  variables  and  routines  global  to  the  object 
is  discouraged.  Hence,  the  order  in  which  the  local  objects'  init  blocks  are 
executed  is  left  undefined. 

2.10   Operation  Invocation. 

Operations  may  be  performed  on  variables   declared   as   objects.    An 

operation  is   executed  by  specifying  the  variable,  a  dot,  the  entry  operation 

and  any  parameters.  This  notation  is  inspired  by  the  Simula   67   dot   notation 

[Dahl  et  al,  68].  For  example,  operations  can  be  invoked  on  variables  declared 

in  examples  above  by 

nextspot. inpointer 
a  [5] .inpointer 
r.f 1. inpointer 

Operations  on  dynamic  variables  are  invoked  by  dereferencing  the  pointer  as  in 

the  examples 
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ptrring~.inpointer 
ptrrec~.f l.inpointer 


2.11   Restrictions. 

Assignments  between  variables  with  the  same  object  type  or  variables 
with  the  same  structured  type  where  that  structured  type  contains  objects  are 
not  permitted  because  of  side-effects  caused  by  the  object  variables'  syn- 
chronization states.  Object  variables  or  structured  variables  that  contain 
objects  are  passed  as  reference  parameters  to  operations. 
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3    OPEN  PATH  EXPRESSIONS. 

Using  processes,  it  is  possible  to  write  programs  in  Path  Pascal  which 
have  several  independent  execution  paths.  It  is  generally  impossible  to  know 
the  order  in  which  processes  will  execute,  or  the  speed  with  which  they  will 
execute.  In  fact,  in  systems  with  multiple  processors,  it  is  possible  for  two 
processes  to  physically  execute  in  parallel.  Because  of  this  uncertainty,  it 
is  important  to  have  a  synchronization  mechanism  which  can  be  used  to  ensure 
the  integrity  of  shared  data. 

The  Open  Path  expressions  notation  for  writing  synchronization  specif- 
ications is  used  in  conjunction  with  objects  to  synchronize  process  execu- 
tions. Shared  data  is  represented  by  an  instance  of  an  object.  Each  object 
contains  exactly  one  path  expression  which  specifies  the  legal  orders  in  which 
the  object's  operations  can  be  executed,  and  the  ways  in  which  these  opera- 
tions can  execute  in  parallel.  Since  only  these  operations  are  used  to  access 
the  data,  processes  trying  to  manipulate  the  data  are  forced  to  do  so  in  safe 
sequences. 

3. 1    Syntax  of  Open  Paths . 


<open  path>  ::=  PATH  <list>  END; 
<list>  ::=  <sequence>    <sequence>  ,  <list> 
<sequence>  ::=  <item>    <item>  ;  <sequence> 
<item>  ::=  <integer  bound>  :  (<list>) 

|  [<list>] 

|  (<list>) 

|  <operation  id> 
<integer  bound>  ::=  <unsigned  integer> 
positive  constant> 


An  Open  Path  expression  is  a  list  of  sequences   separated  by   commas, 
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enclosed  by  the  reserved  words  'PATH'  and  'END'.  A  sequence  is  a  list  of  items 
separated  by  semi-colons.  An  item  can  be  an  operation  name,  or  a  comma 
separated  list  of  sequences  enclosed  by  parentheses,  parentheses  with  an  asso- 
ciated integer  bound,  or  brackets. 

Each  operation  name  must  appear  exactly  once  in  an  Open  Path. 

3.2   Semantics  of  Open  Paths. 

Intuitively,  an  Open  Path  works  in  the  following  manner.  A  process 
tries  to  execute  an  operation.  The  path's  specification  dictates  whether  or 
not  that  operation  can  proceed.  If  it  can,  then  it  does  so  and  the  path  is 
advanced  to  its  next  state.  Otherwise,  the  process  must  wait  until  the  path 
enters  a  state  where  the  operation  that  was  requested  can  be  executed.  Waiting 
processes  are  later  selected  for  execution  in  first-in  first-out  order. 

3.2.1  Grouping  Precedence. 

Semi-colons  have  a  higher  precedence  than  commas.  This  precedence  can 
be  over-ridden  by  the  three  grouping  notations:  parentheses,  parentheses  with 
an  integer  bound,  and  brackets. 

3.2.2  Simplified  Discussion  of  Features. 

This  section  introduces  the  components  of  an  Open  Path.  The  discus- 
sion is  simplified  by  restricting  operands  and  lists  to  single  operation 
names.  The  next  subsection  generalizes  these  features  and  introduces  some 
additional  details. 
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3.2.2.1  Semi-colon. 

A  semi-colon  is  used  to  specify  sequentially .  The  notation  X;Y 
requires  an  execution  of  operation  X  to  precede  an  execution  of  operation  Y, 
and  an  execution  of  Y  may  only  follow  an  execution  of  X. 

3.2.2.2  Comma. 

Commas  specify  a  set  of  alternatives,  any  one  of  which  can  execute 
next.  The  path  X,Y,Z  allows  either  operation  X  or  operation  Y  or  operation  Z 
to  execute  next. 

3.2.2.3  Parentheses  with  Bound. 

This  construct  is  used  to  limit  concurrent  execution.  The  integer 
bound  specifies  the  maximum  number  of  processes  that  can  be  concurrently  exe- 
cuting the  operation  inside  the  parentheses.  A  process  may  immediately  start 
executing  the  enclosed  operation  if  fewer  processes  than  the  specified  integer 
are  concurrently  executing  the  operation.  Specifying  1:  (X)  allows  only  one 
process  at  a  time  to  execute  X,  i.  e.  executions  of  X  must  be  mutually 
exclusive.  The  path  3:  (X)  means  that  at  most  three  processes  can  be  executing 
X  concurrently.  The  bound  may  be  used  to  share  a  limited  number  of  resources 
between  several  processes. 

3.2.2.4  Parentheses . 

Parentheses  without  an  associated  integer  are  equivalent  to 
parentheses  with  an  associated  integer  of  infinity.  They  are  only  used  for 
grouping  and   do   not   limit   concurrent   execution.   The  expression   (X)   is 
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equivalent  to  'infinity:  (X)'  and  allows  up  to  an  unlimited  number  of  con- 
current executions  of  X. 

3.2.2.5  PATH  and  END. 

The  keywords  'PATH'  and  'END'  delimit  the  entire  path  expression  and 
are  equivalent  to  a  pair  of  parentheses.  The  path  PATH  X  END  would  allow  an 
unlimited  number  of  concurrent  executions  of  X. 

3.2.2.6  Brackets. 

Brackets  permit  a  burst  of  execution.  The  burst  begins  when  some  pro- 
cess starts  to  execute  the  operation  enclosed  by  the  bracket.  The  burst  is 
continued  as  long  as  some  process  is  still  executing  the  operation.  While  the 
burst  is  active,  an  unlimited  number  of  processes  can  immediately  begin  the 
operation.  The  burst  ends  when  the  last  process  which  is  executing  the  opera- 
tion completes.  In  the  path  [X]  a  process  can  immediately  start  executing  X 
if  1)  at  least  one  process  is  currently  executing  X,  or  2)  the  path  is  in  a 
state  where  [X]  can  start  executing.  Otherwise,  that  process  must  wait  until 
the  path  enters  a  state  where  [X]  can  be  started  again. 

3.2.3   Full  Discussion  of  Features. 

3.2.3.1   Definitions. 

A  list  of  comma  separated  sequences  is  referred  to  as  an  Open  Path 

list.  Thus  an  Open  Path  expression  is  an  Open  Path  list  enclosed  by  'PATH'  and 

'END'.  Examples  of  Open  Path  lists  are  X,Y,Z  and  V, (W;X;Y) ,2: (Z)  and  the  sim- 
ple list  X- 
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Operation  names  in  an  Open  Path  list  are  called  initial,  intermediate, 
or  final  operations.  Initial  operations  are  those  operations  in  an  Open  Path 
list  which  can  be  executed  when  the  path  is  in  a  state  where  the  Open  Path 
list  can  be  started.  Final  operations  are  those  operations  in  an  Open  Path 
list  whose  execution  puts  the  path  in  a  state  where  the  parts  of  the  Open  Path 
expression  that  follow  the  Open  Path  list  can  start  to  execute.  Intermediate 
operations  are  those  operations  in  an  Open  Path  list  which  can  be  executed 
between  the  Open  Path  list's  initial  and  final  operations.  In  'X,Y,Z',  X,  Y, 
and  Z  are  both  initial  and  final  operations,  and  there  are  no  intermediate 
operations.  In  'V, (W;X;Y) , 2: (Z ) ' ,  V,  W,  and  Z  are  initial  operations,  X  is  an 
intermediate  operation,  and  V,  Y,  and  Z  are  final  operations. 

A  sequence  of  operation  executions  that  starts  with  one  of  an  Open 
Path  list's  initial  operations  and  ends  with  one  of  its  final  operations  is 
called  an  execution  sequence.  In  'V, (W;X;Y)'  ,  V  is  an  execution  sequence  and 
so  is  W,  X,  and  Y.  A  sequence  of  operation  names  can  be  used  in  more  than  one 
execution  sequence.  For  example,  two  processes  can  be  concurrently  executing  V 
according  to  the  above  Open  Path  list  yielding  two  similar  execution 
sequences,  V  and  V. 

The  grouping  notations  inherit  the  characteristics  of  the  Open  Path 
list  which  they  enclose.  Thus  brackets  in  [V,(W;X;Y)]  have  initial  operations 
of  V  and  W,  and  an  execution  sequence  of  W,  X,  and  Y. 

3.2.3.2   Brackets . 

Brackets  are  used  for  grouping  and  to  provide  a  special  burst  mode  of 
execution.  A  burst  of  execution  is  started  when  one  of  the  bracket's  initial 
operations  is  executed  and  continues  as  long  as  any  of  the  bracket's  execution 
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sequences  is  unfinished.  One  of  the  bracket's  initial  operations  can  be  exe- 
cuted immediately  if  one  of  the  bracket's  execution  sequences  is  unfinished. 

There  are  two  special  rules  for  brackets.  First,  while  a  bracket's 
operations  must  wait  to  start  until  some  execution  sequence  progresses  to  the 
point  where  the  bracket  is  reached,  once  the  bracket  has  been  started  (entered 
burst  mode)  an  unlimited  number  of  the  bracket's  operations  can  start  immedi- 
ately as  long  as  one  of  the  bracket's  execution  sequences  is  still  unfinished. 
Second,  only  one  execution  sequence  can  contain  the  bracket  in  burst  mode;  i. 
e.  a  bracket  must  be  executed  in  mutual  exclusion.  This  rule  is  a  result  of 
the  decision  to  continue  an  old  burst  instead  of  start  a  new  one  when  the 
bracket  is  in  burst  mode. 

3.2.3.3   Parentheses  with  Bound. 

This  construct  is  used  for  grouping  and  to  limit  concurrent  execution. 
It  states  that  at  most  n  execution  sequences  can  proceed  concurrently  (n  is 
the  associated  integer).  If  there  are  fewer  than  n  concurrent  execution 
sequences,  one  of  the  parentheses'  initial  operations  can  be  executed  immedi- 
ately. 

There  is  a  special  rule  when  this  construct  is  nested.  If  an  attempt 
is  made  to  execute  an  operation  which  is  nested  within  several  pairs  of 
parentheses  and  which  could  execute  if  not  limited  by  one  of  these  constructs, 
the  execution  restrictions  associated  with  the  parentheses  are  examined  from 
the  innermost  level.  If  execution  is  restricted  then  the  process  that  was  try- 
ing to  execute  the  operation  waits  at  the  level  where  it  was  stopped.  When  the 
restriction  is  removed,  checking  continues  from  that  point.  In  the  path 
i:  (Y,2:  (Z)),   assuming  that  the  execution  sequences  Z  and  Z  are  unfinished  (i. 
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e.  two  processes  are  executing  Z),  a  process  now  attempting  to  execute  Z  will 
be  stopped  by  2:(Z).  If  another  process  then  attempts  to  execute  Y  it  wili  be 
permitted  to  continue.  The  third  attempt  to  execute  Z  would  not  have  'used  up' 
one  of  the  outer  parentheses'  execution  sequences.  This  rule  helps  prevent 
poor  system  performance. 

3.2.3.4  Parentheses. 

Parentheses  are  used  for  grouping  and  are  equivalent  to  parentheses 
with  an  associated  integer  of  infinity. 

3.2.3.5  PATH  and  END. 

'PATH'  and  'END'  are  equivalent  to  a  pair  of  parentheses  end  enclose 
the  Open  Path  expression. 

3.2.3.6  Semi-colon. 

The  path  LI;  L2  (where  LI  and  L2  are  open  path  lists)  allows  L2  to 
being  only  after  some  LI  is  completed. 

3.2.3.7  Comma- 

Any  of  the  operands  in  a  comma  separated  list  can  be  group  enclosed 
Open  Path  lists.  The  path  LI,  L2,  ...,  Ln,  allows  any  one  initial  operation  of 
any  of  the  operands  to  be  executed.  Thus  any  one  execution  sequence  from  the 
operands  can  be  executed. 
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3.3   Examples  of  Open  Paths. 

1.  PATH  A  END; 

A  can  execute  at  any  time,  and  any  number  of  A's  can  execute  concurrently. 
The  synchronization  that  is  specified  is  trivial. 

2.  PATH  A,B,C  END; 

A  or  B  or  C  can  execute  at  any  time.  Any  number  of  A's,  B's,  and  C's  can 
execute  concurrently.  The  synchronization  that  is  specified  is  trivial. 

3.  PATH  A;B  END; 

A's  can  be  executed  at  any  time.  A  B  can  only  be  executed  if  the  number  of 
B's  that  completed  or  are  currently  executing  is  less  than  the  number  of 
A's  that  are  completed.  Any  process  that  is  given  permission  to  execute 
can  execute  concurrently  with  any  other  process. 

4.  PATH  1:  (A)  END; 

A's  must  be  executed  sequentially. 

5.  PATH  2:  (A)  END; 

At  most  two  A's  can  execute  concurrently. 

6.  PATH  1: (A),B  END; 

A's  must  execute  sequentially.  B's  can  execute  at  any  time.  Any  processes 
that  are  given  permission  to  execute  can  execute  concurrently. 

7.  PATH  1: (A),l: (B)  END; 

A's  must  execute  sequentially,  and  B's  must  execute  sequentially.  One  A 
and  one  B  can  execute  concurrently,  however. 

8.  PATH  1: (1: (A),l: (B))  END; 

Processes  A  and  B  execute  in  mutual  exclusion.  The  expression  PATH  1: (A, 
B)  END  would  be  better. 


Page  21 


9.  PATH  5: (A;B)  END; 


At  most  five  execution  sequences  can  be  executing  concurrently.  Thus  at 
most  5  A's  and  0  B's  can  be  executing  concurrently,  or  4  A's  and  1  B,  etc. 
In  addition,  the  number  of  B's  tht  are  executing  or  completed  must  be  less 
than  the  number  of  A's  that  are  completed. 


10.  PATH  1: (1: (A),B)  END; 

The  outer  parentheses  specifies  that  only  one  A  or  one  B  can  execute  at  a 
time,  and  that  they  cannot  execute  concurrently.  The  inner  parentheses 
allow  B's  to  be  given  priority  over  A's.  This  occurs  because  processes 
trying  to  execute  A's  must  first  get  past  the  restriction  of  the  inner 
parentheses,  while  processes  trying  to  execute  B's  can  go  directly  to  the 
outer  parentheses. 

11.  PATH  1:  (  [A]  ,B)  END; 

Either  a  burst  of  A's  or  a  B  can  execute,  but  not  concurrently.  The  A's  in 
the  burst  of  A's  must  execute  concurrently.  When  the  burst  ends,  a  B  will 
start  if  a  process  is  waiting  to  execute  a  B.  Otherwise,  either  a  burst  of 
A's  or  a  B  will  be  executed  depending  upon  whether  an  A  or  a  B  is 
requested  first. 


12.  PATH  3:  ([A])  END; 

This  path  is  equivalent  to  PATH  1:([A])  END;,  PATH  [A]  END;,  and  PATH  A 
END;  because  bursts  must  execute  sequentially  and  there  is  no  difference 
between  sequential  bursts  of  A's  and  the  unrestricted  execution  of  A's. 


13.  PATH  5: (3: (A), 4: (B))  END; 

At  most  3  A's  can  execute  sequentially,  and  at  most  4  B's  can  execute 
sequentially.  The  outer  parentheses  allow  at  most  5  concurrent  execution 
sequences,  so  at  most  3  A's  and  2  B's,  or  2  A's  and  3  B's,  etc.  can  exe- 
cute concurrently.  The  bounded  parentheses  can  be  used  to  allocate 
resources.  The  above  expression  could  be  used  to  allocate  five  resources 
to  two  sets  of  processes  invoking  A  and  B  so  that  there  is  always  one 
resource  available  for  the  set  requesting  A  and  two  resources  available 
for  the  set  requesting  B. 


14.  PATH  8: (3: (A), 3: (B))  END; 

This  path  is  equivalent  to  PATH  6: (3: (A) , 3: (B ) )  END.  Setting  the  outer 
integer  to  8  is  superfluous.  At  most  3  A's  can  execute  concurrently,  and 
at  most  3  B's  can  execute  concurrently.  Also,  all  3  A's  and  all  3  B's  can 
execute  concurrently. 
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15.  PATH  TOTAL:(AMAX:(A),BMAX:(B))  END; 

If  TOTAL,  AMAX,  BMAX,  are  integer  constants  5,  3,  and  4,  then  this  path  is 
identical  to  the  path  in  13. 
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A    PROCESSES. 

A  process  is  a  program  structuring  unit  which  has  an  independent 
execution  path  associated  with  it.  Processes  can  interact  and  are  co- 
ordinated by  performing  operations  on  shared  variables.  The  declaration  of  a 
process  is,  in  Path  Pascal,  distinguished  from  the  activation  of  a  process.  A 
process  may  be  declared  in  any  block  and  activations  of  the  process  may  be 
created  in  any  body  of  code  with  scope  that  includes  the  declaration. 

4.1    Process  Syntax. 


<process  declaration>  ::= 

<process  heading>  <block> 


<process  heading>  ::  = 

PROCESS  <identifier>  <size  part>;  | 
PROCESS  <identifier>  <size  part> 
(<formal  parameter  section> 

{;<formal  parameter  section>}); 


<size  part>  : : = 

[<unsigned  integer>] 


Processes  are  declared  like  standard  Pascal  procedures.  They  may 
possess  parameters,  but  may  also  have  a  size  attribute.  The  parameters  can  be 
passed  by  value  or  by  reference.  The  size  attribute  is  used  to  estimate  the 
process's  storage  requirements.   If  it  is  omitted  a  default  value  is  used. 

An  example  of  a  process  declaration  is: 
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1  PROCESS  printer  [200]  (  VAR  inbuff  :  buffer); 

2  VAR  outbuff  :  buffer;   ch  :  CHAR; 
3 

4  PROCEDURE  asciitoebcdic  (  ch  :  CHAR); 

5  BEGIN 

6  outbuff. fill(ch) 

7  END; 
8 

9  PROCESS  reader; 

10  VAR  ch  :  CHAR; 

11  BEGIN 

12  REPEAT 

13  ch  :=  inbuff .empty; 

14  asciitoebcdic(ch) 

15  UNTIL  false 

16  END; 
17 

18  BEGIN 

19  reader;     (*  instantiate  a  reader  process  *) 

20  REPEAT     (*  simulate  a  writer  *) 

21  ch  :=  outbuff .empty; 

22  write(ch) 

23  UNTIL  false 

24  END;   (*  printer  *) 


This  example  contains  a  printer  which  manipulates  and  then  prints  sequences  of 
characters.  The  printer  has  one  parameter,  'inbuff  a  variable  of  type 
'buffer'  ,  and  a  size  attribute  of  200.  The  size  attribute  indicates  that  200 
words  will  be  required  at  run-time  to  contain  the  stack  and  heap  for  the  pro- 
cess printer.  The  200  words  are  required  for  the  local  variables  and  for 
invocations  of  routines.  'Reader'  transforms  ascii  characters  in  'inbuff  to 
ebcdic  characters  using  'asciitoebcdic'.  The  ebcdic  characters  are  placed  in 
'outbuff  and  then  printed  using  the  write  loop. 

4 .  2    Creating  a_   Process. 

An  instance  of  a  process  is  dynamically  created  by  invoking  the  pro- 
cess name  ,  Just  as  in  a  procedure  invocation.  This  can  be  seen  in  line  19  in 
the  above  example  where  the  reader  process  is  created.   The  creating  process 
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does  not  have  to  wait  for  the  created  process  to  terminate  before  continuing 
its  own  execution.  Each  process  created  is  allocated  a  run-time  heap  and 
stack  from  the  heap  of  the  process  which  is  performing  the  creation.  The 
number  of  words  allocated  is  specified  by  the  size  attribute,  but  if  this 
attribute  is  omitted  a  system  default  of  100  words  is  used.  No  mechanism  is 
provided  to  abnormally  terminate  a  process.  A  process  terminates  only  when  it 
reaches  the  end  of  its  code  body. 

4 .  3   Process  Storage  Considerations. 

A  process's  storage  may  be  explicitly  released  and  reused  with  the 
procedures  MARK  and  RELEASE  just  like  dynamic  variable  storage.  It  is  not 
automatically  released  when  a  process  terminates.  Note,  however,  that  it  is  an 
error  to  release  this  storage  before  a  process  completes  just  as  it  is 
incorrect  to  release  a  dynamic  variable's  storage  before  reaccessing  that 
variable.  Also,  notice  that  MARK  will  only  refer  to  the  active  process's  local 
heap . 

4.4   Process  Lifetimes. 

The  lifetime  of  a  block  which  contains  a  process  declaration  is  at 
least  as  long  as  the  lifetime  of  any  activation  of  that  process.  Intervening 
blocks  between  the  block  that  contains  the  process  declaration  and  the  pro- 
cess creation,  can  complete  before  the  process  completes.  Thus  a  block  B 
(which  does  not  contain  the  process  declaration)  can  create  a  process,  con- 
tinue executing,  and  then  return  control  to  its  calling  block.  Later  control 
can  reenter  block  B  and  another  creation  of  the  process  can  be  made,  even  if 
the   first   process   is  still  executing.  If  an  attempt  is  made  to  exit  a  block 
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which  contains  a  process  declaration  for  which  there  is  an  existing  activa- 
tion, the  exit  will  be  delayed  until  that  process  completes.  The  following 
example  illustrates  these  points. 

PROGRAM  example(  input,  output); 
VAR  w  :  INTEGER; 
PROCESS  a;   BEGIN  ...  END  (*a*); 

PROCEDURE  b(VAR  x  :  INTEGER); 
VAR  y  :  CHAR; 

PROCEDURE  c(VAR  z  :  CHAR); 
BEGIN 

a 
END  (*c*); 

BEGIN 
c(y) 
END  (*b*); 

BEGIN 
b(w) 
END  (*example*). 

The  program  block  calls  'b'  which  calls  'c'  which  creates  process  'a'. 
*c*  can  then  continue  executing  and  complete,  returning  control  to  'b'.  The 
process  'b'  can  now  continue  executing  in  parallel  with  the  activation  of  'a' 
and  can  complete,  returning  control  to  the  program  block.  The  program  block 
can  continue  executing,  but  it  cannot  complete  until  process  'a'  has  ter- 
minated. 

4 . 5   Parameter  Restriction. 

The  scope  of  an  actual  parameter  which  is  passed  by  reference  to  a  process 
must  contain  scope  of  the  process's  declaration.  Consider  the  following  exam- 
ple where  this  rule  is  violated: 
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PROCESS  a  (VAR  x  :  INTEGER);  BEGIN  ...  END; 
PROCEDURE  b; 

VAR  y  :  INTEGER; 
BEGIN 

a(y) 
END; 
PROCEDURE  c;  BEGIN  ...END; 


Calling  'b'  creates  'a'  and  passes  'y*  by  reference,  completes,  and 
returns  its  activation  record  to  the  run-time  stack.  The  routine  which  called 
'b'  might  now  call  'c'  whose  activation  record  will  overlay  some  or  all  of  the 
space  where  'b's  old  activation  record  was  stored.  If  'a'  is  still  executing 
and  it  writes  into  'y',  it  will  erroneously  write  into  'c's  activation  record. 

4.6   Priorities. 

One  of  two  static  priority  schemes  can  be  associated  with  processes  in 
order  to  provide  rudimentary  control  over  process  scheduling.  In  the  first 
scheme,  all  processes  have  the  same  priority.  In  the  other,  priority  is  deter- 
mined by  the  static  nesting  level  of  a  process's  declaration,  with  processes 
declared  at  the  outermost  levels  having  the  highest  priority.  Within  a  given 
priority  level,  a  process  is  selected  for  execution  by  a  first-in  first-out 
scheduler.  If  the  level  oriented  scheme  is  used  in  the  above  example,  then  the 
writer  has  higher  priority  than  the  reader  and  the  device  driven  by  'write' 
(line  22)  is  kept  as  busy  as  possible.  The  second  priority  scheme  is  selected 
by  default,  but  equal  priorities  can  be  chosen  by  specifying  the  NP  option  on 
the  interpreter  command  card. 
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4.7  Delaying  Processes. 

A  process  can  be  delayed  for  a  fixed  time  interval  by  calling  the  pro- 
cedure DELAY.  An  integer  argument  specifies  how  long  the  process  is  to  be 
delayed.  The  number  of  simulated  time  units  which  have  elapsed  since  execu- 
tion began  can  be  obtained  from  the  parameterless  function  TIME  which  returns 
an  integer  value. 

4.8  Interrupt  Processes. 

Interrupt  processes  are  used  in  Path  Pascal  to  program  input  and  out- 
put devices  of  the  computer.  The  DOIO  statement  is  used  within  the  interrupt 
process  to  suspend  it  while  input  or  output  is  being  performed.  Only  one  DOIO 
statement  is  allowed  within  the  process  block.  The  DOIO  statement  may  not  be 
used  in  regular  processes.  The  interrupt  process  mechanism  is  based  on  Modula 
[Wirth,77]  and  its  syntax  is  show  below  in  BNF: 


<process  declaration  ::  = 

INTERRUPT  interrupt  process  heading>  <block> 


<interrupt  process  heading>  ::«= 

PROCESS  <identifier>  interrupt  params>;  | 
PROCESS  <Identifier>  <interrupt  params> 
(  <formal  parameter  section> 

{  ;  <formal  parameter  section>  }  ); 


<interrupt  params>  ::^ 

[  PRIORITY  -  <unsigned  integer>  ; 
VECTOR  -  <address>] 


<address>  ::-  //<unslgned  octal  integer> 
<unsigned  integer> 


mp le:- 
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INTERRUPT    PROCESS    print 

[PRIORITY   -   4    ;    VECTOR   =   #64]     (buf    :    linebuffer); 

VAR 

1: INTEGER; 

pts [#177564] :bits;  (*printer  status  word*) 

ptb  [#177566] :char;  (*printer  buffer  word*) 

BEGIN 

i  :«  0; 
REPEAT 

i  :=  1+1; 

pts  :=  [6];  (*enable  printer  interrupt*) 
ptb  :=  buf  [i];  (*print  a  character*) 
DOIO;  (*wait  for  the  interrupt  to  occur*) 
pts  :=  pts-[6];  (*disable  printer  interrupt*) 
UNTIL  ((  i  >=  linesize  )  OR  (buf[i]  =  cr)); 
END;  (*end  of  process  print*) 


The  interrupt  parameter  is  used  to  store  the  interrupt  vector  of  the 
process  at  the  correct  place  in  memory  and  set  the  priority  of  the  process.  In 
the  example,  the  vector  will  be  stored  at  octal  location  64  and  the  priority 
of  the  process  will  be  4.  (On  the  PDP11,  the  priority  of  the  processor  is  set 
to  the  priority  of  the  process  it  is  running.  Interrupts  from  devices  can 
only  affect  the  process  when  the  process  priority  is  less  than  the  priority  of 
the  interrupting  device.  Other  processes  run  with  a  processor  priority  of  0. ) 

Interrupt  processes  are  created  in  exactly  the  same  manner  as  other 
processes.  Running  duplicate  interrupt  processes  or  terminating  an  interrupt 
process  while  an  interrupt  is  pending  is  discouraged. 

The  device  registers  of  the  printer  are,  in  this  example,  at  location 
#177564  and  #177566.  To  allow  programs  to  access  device  registers,  variables 
can  be  associated  with  the  absolute  device  addresses. 


<variable  declaration>  ::= 

<name>    {,    <name>>    :    <type> 
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<name>  ::■  <identifier> 

<identif ier> [<address>] 


Thus,  "pts"  and  'ptb"  are  declared  to  be  the  status  and  data  registers  of  the 
printer.  The  variable  "pts"  is  declared  to  be  of  type  "bits",  a  set  of  numbers 
from  1  to  16.  The  interrupt  for  the  printer  is  enabled  by  writing  a  bit  into 
the  status  register.  This  is  performed  above  using  one  of  the  operations  on 
sets.  The  DOIO  statement,  when  executed,  suspends  the  process  until  the  inter- 
rupt is  received.  Another  process  is  removed  from  the  ready  queue  and  run. 
Machine  dependent  features  such  as  device  addresses  and  the  DOIO  statement  are 
restricted  in  their  use  to  the  block  of  an  interrupt  process. 
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5    SUMMARY. 

The  Path  Pascal  programming  language  is  an  extension  of  Pascal  P4  which 
includes  concurrent  processes,  processes  for  controlling  I/O  devices,  path 
expressions,  and  objects.  The  Path  Pascal  compiler  is  written  in  Pascal  P4 
and  is  self -compiling.  An  intermediate  code  (an  extended  P-Code)  is  produced 
by  the  Path  Pascal  compiler  and  can  either  be  executed  interpretively  or 
assembled  into  machine  instructions.  The  language  can  be  used  to  simulate  sys- 
tens,  as  an  educational  tool,  or  to  construct  system  and  real-time  programs. 
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APPENDIX  A 
PATH  PASCAL  SYNTAX 

The  following  Backus-Naur  form  (BNF)  grammar  summarizes  the  syntax  of 
Path  Pascal.  This  list  of  rules  only  contains  the  additions  to  standard  Pas- 
cal. The  following  symbols  are  meta-symbols  belonging  to  the  BNF  formalism  and 
are  not  symbols  of  the  language  Path  Pascal. 

I       ::«       {   > 

The  curly  braces  denote  the  possible  repetition  of  the  enclosed  symbols   zero 
or  more  times. 


<block>  ::= 

<label  declaration  part> 
<constant  definition  part> 
<type  definition  part> 
<variable  declaration  part> 
<routine  part> 
<statement  part> 


<unpacked  structured  type>  ::■ 
<array  type> 
<record  type>  | 
<object  type>  | 
<set  type>  | 
<file  type> 


<object  type>  ::=  OBJECT  <object  block>  END 


<object  block>  ::- 

<path  declaration  part> 

<constant  definition  part> 

<type  definition  part> 

<object  variable  declaration  part> 

<operation  declaration  part> 

<initialization  part> 
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<path   declaration  part> 
<empty>    | 
<open  path> 


<open  path>    ::=  PATH   <list>   END; 


<list>  ::= 

<sequence> 
<sequence>  ,  <list> 


<sequence>  :  :  = 
<item>  | 
<item>  ;  <sequence> 


<item>  : : = 

<integer  bound>  :  (  <list>  ) 
[  <list>  ]  | 
<operation  id>  | 
(  <list>  ) 


<bound>  ::=  <unsigned  integer> 
<positive  constant> 


<operation  id>  ::= 
<identifier> 


<object  variable  declaration  part>  ::= 
VAR  <variable  declaration> 

{  ;  <variable  declaration>  }   ; 


<operation  declaration  part> 
{  <operation  part>  } 


<operation  part>  : 
<routine>  | 
<operation> 


<routine  part>  : :» 
{  <routine>  } 
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<routine>    : :■ 

<procedure   declaration> 
<function   declaration> 
<process   declaration 


<operation>    : : - 

ENTRY   <routine> 


<process   declaration>    ::■ 

<process  heading>    <block>    | 

INTERRUPT    <interrupt   process   heading>    <block> 


process  heading>    :  :  = 

PROCESS   <identifier>   <size  part>;    | 
PROCESS    <identifier>    <size  part> 
(    <formal  parameter  section> 

{    ;    <formal  parameter   section>   >    ); 


<size  part>  : : ■ 

[  <unsigned  integer>  ] 


<interrupt  process  heading>  ::= 

PROCESS  <identifier>  interrupt  params>;  | 
PROCESS  <identifier>  <interrupt  params> 
(  <formal  parameter  section> 

<  ;  <f ormal  parameter  section>  }  ) ; 


<interrupt  params>  ::■ 

[  PRIORITY  =  <unsigned  integer>  ; 
VECTOR  -  <address>] 


<address>  : :=  #<unsigned  octal  integer> 
<unsigned  integer> 


<Variable  declaration  :  :* 

<name>  {,  <name>)  :  <type> 


<name>  ::«  <identifier>  | 

<identifier> [   <address>] 
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<simple  statements  ::■ 

assignment  statement>  | 
<procedure  statement>  | 
<proces8  statement>  | 
<go  to  statement>  | 
<object  procedure  statement> 
<object  process  statement>  | 
DOIO  | 
<empty> 


<object  variable>  :  :  = 
<variable> 


<component  variable>  :  :  = 
<indexed  variable>  | 
<field  designator>  | 
<file  buffer>  | 
<object  designator> 


<object  designator>  ::= 

<record  variable>  .  <object  identifier> 


<object  identifier>  ::= 
<identifier> 


<factor>  ::«= 

<variable>  | 

<unsigned  constant>  | 

(  <expression>  )  | 

<function  designator>  | 

<object  function  designator> 

<set>  | 

NOT  <factor> 


<object  function  designator>  ::= 

<object  variable>  .  <function  designator> 


<object  procedure  statement>  : :  ■ 

<object  variable>  .  procedure  statement> 


<object  process  statement>  ::- 

<object  variable>  .  <process  statement> 
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<process   statement>    ::■ 

<process    identifier>    | 

<proce8s   identif ier>    (    <actual  parameter> 
{    ,    <actual  parameter>    }    ) 
initialization  part>    :  :« 

<enpty>    | 

INIT;    <block> 
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APPENDIX  B 

ERROR  MESSAGES,  CONTROL  OPTIONS,  AND  CONSTANTS 

This  appendix  contains  information  related  to  the  Path  Pascal  compiler 
and  interpreter.  First,  compiler  options,  an  important  compiler  constant,  and 
error  messages  issued  by  the  compiler  are  listed.  This  is  followed  by  the 
interpreter  control  statement  options,  major  constants,  load-time  error  mes- 
sages, and  run-time  error  messages. 


B.l   PATH  PASCAL  COMPILER  OPTIONS 


$T  print  tables     (default  -) 

$L  print  listing   (default  +) 

$D  debug  mode      (default  +) 

$C  generate  code    (default  +) 

$S  report  local  storage  per  block  (default  +) 


B.2   PATH  PASCAL  COMPILER  CODE  AND  CONSTANTS 


To  convert  the  Path  Pascal  compiler  from  Pascal  6000  to  Pascal  P4, 
remove  the  three  portions  of  code  enclosed  between  comments  (**P4REM0VE**)  and 
(**P4ENDREM0VE**). 

LCAFTERMARKSTACK-7;     Must  have  the  same  value  as   the  inter- 
preter constant  of  the  same  name 
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B.3   PATH  PASCAL  ERROR  MESSAGES 


1 

2 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 


Error  in  simple  type. 

Identifier  expected. 

")'*  expected. 

":"  expected. 

Illegal  symbol. 

Error  in  parameter  list. 

M0F"  expected. 

"("  expected. 

Error  in  type. 

"["  expected. 

"]  "  expected. 

"END"  expected. 

";"  expected. 

Integer  expected. 

"="  expected. 

"BEGIN"  expected. 

Error  in  declaration  part. 

Error  in  field-list. 

","  expected. 

"*"  expected. 


50 
51 
52 
53 
54 
55 
58 
59 


Error  in  constant. 

":■"  expected. 

"THEN"  expected. 

"UNTIL"  expected. 

"DO"  expected. 

"TO"  or  "DOWNTO"  expected. 

Error  in  factor. 

Error  in  variable. 


101 
102 
103 
104 
105 
106 
107 
108 
109 
110 
111 
113 
114 
115 
116 
117 
119 
120 


Identifier  declared  twice. 

Low  bound  exceeds  high  bound. 

Identifier  is  not  of  appropriate  class. 

Identifier  not  declared. 

Sign  not  allowed. 

Number  expected. 

Incompatible  subrange  types. 

File  not  allowed  here. 

Type  must  not  be  real. 

Tagfield  type  must  be  scalar  or  subrange. 

Incompatible  with  tagfield  type. 

Index  type  must  be  scalar  or  subrange. 

Base  type  must  not  be  real. 

Base  type  must  be  scalar  or  subrange. 

Error  In  type  of  standard  procedure  parameter. 

Unsatisfied  forward  reference. 

Forward  declared;  repetition  of  parameter  list  not  allowed. 

Function  result  type  must  be  scalar,  subrange  or  pointer. 
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File  value  parameter  not  allowed. 

Forward  declared  function;  repetition  of  result  type  not  allowed. 

Missing  result  type  in  function  declaration. 

F-format  for  real  only. 

Error  in  type  of  standard  function  parameter. 

Number  of  parameters  does  not  agree  with  declaration. 

Result  type  of  parameter/function  does  not  agree  with  declaration. 

Type  conflict  of  operands. 

Expression  is  not  of  set  type. 

Tests  on  equality  allowed  only. 

Strict  inclusion  not  allowed. 

File  comparison  not  allowed. 

Illegal  type  of  operand (s). 

Type  of  operand  must  be  boolean. 

Set  element  type  must  be  scalar  or  subrange. 

Set  element  types  not  compatible. 

Type  of  variable  is  not  array. 

Index  type  is  not  compatible  with  declaration. 

Type  of  variable  is  not  record. 

Type  of  variable  must  be  file  or  pointer. 

Illegal  parameter  substitution. 

Illegal  type  of  loop  control  variable. 

Illegal  type  of  expression. 

Type  conflict. 

Assignment  of  files  not  allowed. 

Label  type  incompatible  with  selecting  expression. 

Subrange  bounds  must  be  scalar. 

Index  type  must  not  be  integer. 

Assignment  to  standard  function  is  not  allowed. 

Assignment  to  formal  function  is  not  allowed. 

No  such  field  in  this  record. 

Actual  parameter  must  be  a  variable. 

Control  variable  must  be  neither  formal  nor  global. 

Multidefined  CASE  label. 

Too  many  CASEs  in  CASE  statement. 

Missing  corresponding  variant  declaration. 

REAL  or  STRING  tagfields  not  allowed. 

Previous  declaration  was  not  forward. 

Again  FORWARD  declared. 

Parameter  size  must  be  constant. 

Multidefined  label. 

Multideclared  label. 

Undeclared  label. 

Undefined  label. 

Cannot  pass  a  procedure,  function,  or  process  as  a  formal  parameter 

Duplicate  value  in  varient  record. 


Error  in  real  constant;  digit  expected. 
String  constant  must  not  exceed  source  line. 
Integer  constant  exceeds  range. 


250:   Too  many  nested  scopes  of  identifiers 
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251:  Too  many  nested  procedures  and/or  functions 
254:   Too  many  LONG  constants  in  this  procedure. 


304:   Element  expression  out  of  range 


381:  GOTO  leads  out  of  procedure. 

382:  Illegal  Symbol. 

383:  String  too  long. 

384:  Real  Pointers  not  allowed  for  rangetype. 

385:  Strings  not  available  here. 

386:  Files  not  supported. 

387:  Procedure  not  allowed. 

388:  Function  not  allowed. 

389:  Only  get,  put  available  here. 

390:  Character  files  required. 

391:  Only  CHARacter  type  allowed  here. 

392:  Only  character  files  allowed. 

393:  Real  pointer  not  allowed. 

394:  Scalar  not  allowed. 

395:  PACK  not  allowed. 

396:  UNPACK  not  allowed. 

397:  Passed  argument  must  not  be  function  or  procedure. 


401:  Invalid  parenthesis  in  path. 

404:  Unable  to  find  procedure  entry  in  path. 

409:  Passed  variable  has  nesting  level  too  high. 

410:  Interrupt  process  expected. 

412:  Expecting  declaration  within  object. 

413:  Indexed  variable  not  allowed. 

414:  Indirection  limit  exceeded  (compiler  error) 

415:  Expecting  STRING. 

416:  Expression  not  allowed. 

417:  Undefined  entry,  procedure  or  function. 


429:   PP  stack  overflow. 
430:   VV  stack,  overflow. 


500:   Files  not  supported. 

501:   Variants,  tagflds  not  allowed. 

502:   Files,  tagflds,  variants  not  allowed. 


701:   Expected  stack,  priority,  or  vector. 

702:   Machine  dependent  declarations  must  be  in  interrupt  processes 
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B.4   INTERPRETER  CONTROL  STATEMENT  OPTIONS 


/LNLMT  -  Remove  line  limit  restrictions  on  OUTPUT  and  PRR. 

-  Default  line  limit  is  500  lines. 

/TRACE  -  Display  HSC  machine  registers  after  each  pcode  instruction. 

-  Default  action  is  no  display. 

/NP    -  Do  not  assign  priorities  to  processes. 

-  The  default  action  is  to  assign  priority  to  processes  according   to 
their  static  nesting  level.   (See  section  5.6  for  more  details.) 


/DEBUG  -  Generate  a  trace  of  process  executions 
-  The  default  action  is  no  trace 


B.5   INTERPRETER  CONSTANTS 


CODEMAX-8192; 
PCMAX»C0DEMAX*2; 
MAXSTR-OVERM+1 ; 
OVERM=8000; 
OVERBOVERM-4180; 
OVERS  =OVERB-90; 
OVERR-OVERS-70; 
OVERI-OVERR-5; 
MAXSTK«OVERI-5(=3650) ; 

TIMESLICE-1000; 

LCAFTERMARKSTACK-7 ; 


Number  of  code  space  words 

Generate  2  instructions  per  word 

Used  to  test  whether  addresses  are  in  range 

Number  of  data  space  words 

Reserve  4180  words  for  character  strings 

Reserve  90  words  for  boundary  information 

Reserve  70  words  for  sets 

Reserve  space  for  5  REAL  constants 

Reserve  space  for  5  INTEGER   constants   (Note   that 
3650  words  remain  for  the  stack  and  heap.) 

Number  of   instructions   executed  between  process 
switches 

Must  have  the  same  value  as  the  compiler   constant 
of  the  same  name 


Page  B-6 


B.6   INTERPRETER  LOAD-TIME  ERROR  MESSAGES 


DUPLICATED  LABEL 
ILLEGAL  INSTRUCTION 
INTEGER  TABLE  OVERFLOW 

REAL  TABLE  OVERFLOW 

ILLEGAL  CHARACTER 

SET  TABLE  OVERFLOW 

BOUNDARY  TABLE  OVERFLOW 

MULTIPLE  TABLE  OVERFLOW 


Unknown  opcode  in  pcode 

Too  many  integer  constants   (to  fix  alter  inter- 
preter constant  OVERI) 

Too  many  real  constants  (to  fix  alter  interpreter 
constant  OVERR) 

Character  constant  mist  be  enclosed  in  single 
quotes  (e.g. ,  'x' ) 

Too  many  set  constants  (to  fix  alter  interpreter 
constant  OVERS) 

Too  many  bounds  (array  bounds  or  subranges)  (to  fix 
alter  interpreter  constant  OVERB) 

Too  many  character  strings   (to  fix  alter  inter- 
preter constant  OVERM) 


B.7   INTERPRETER  RUN-TIME  ERROR  MESSAGES 


UNINITIALIZED  SEMAPHORE 

GET  ON  OUTPUT  FILE 
GET  ON  PRR  FILE 
PUT  ON  READ  FILE 
PUT  ON  PRD  FILE 
READLN  ON  OUTPUT  FILE 
WRITELN  ON  INPUT  FILE 
WRITELN  ON  PRD  FILE 
WRITE  ON  INPUT  FILE 
WRITE  ON  PRD  FILE 
READ  ON  OUTPUT  FILE 


Illegal  use  of  uninitialized  semaphore.   (Probably 
due  to  compiler  error.) 


READ  ON  PRR  FILE 
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EOLN  OUTPUT  FILE 
EOLN  ON  PRR  FILE 


EOLN  only  permitted  on  INPUT  and  PRD 


STORE  OVERFLOW  Possible  causes 

-  Heap  exhausted  due  to  NEW 

-  Heap  exhausted  due  to  processes  activation  (PST ) 

-  Stack  exhausted  due  to  activation  record  (ENT  1) 

-  Stack  exhausted  due  to  procedure  temporary  space 
(ENT  2) 

<,<-»>.>"  FOR  ADDRESS      Only  -  and  <>  can  be  used  with  a  pointer 


SET  INCLUSION 


Only  "t    <>,  <■,  >=  can  be  used  with  a  set 


BAD  POINTER  VALUE 


Pointer  not  within  heap 


VALUE  OUT  OF  RANGE 


CODE  IN  ERROR 


EOF  can  only  be  used  with  INPUT 


CASE  -  ERROR 


No  case  provided  for  this  value 


RDY  AND  EVNT  QUES  EMPTY    All  processes  waiting  for  semaphores;   program  is 

deadlocked 
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SEMANTICS  AND  REDUCTION  ALGORITHM  FOR  OPEN  PATHS 


Open  Path  semantics  are  described  below  in  terms  of  P  and  V  operations 
on  counting  semaphores  in  the  prologues  and  epilogues  of  the  procedures,  func- 
tions, and  processes.  The  following  recursive  algorithm  [Campbell,  77]  will 
translate  open  paths  into  this  P  and  V  implementation.  In  general,  the  path 
expression  to  be  translated  will  be  surrounded  by  two  strings  of  generated 
synchronization  operations  which  are  on  its  left  and  right  (L  and  R  respec- 
tively.) The  following  set  of  transformation  rulesis  applied  in  the  order 
given  by  the  parse  tree  or  derivation  of  the  path  expression  using  the  produc- 
tion rules  above.   The  notation  "[init:   sx  <-  y]M  denotes  initializing  sx  to 

y- 

Initialization  of  reduction  algorithm: 

Replace:  "PATH  list  END" 

by:  "list"   (L  and  R  are  empty  strings) 

The  comma  is  used  as  a  distributive  mechanism  for  the  synchronization 
in  which  it  is  embedded: 

Replace:  "L  sequence,  list  R" 

by:  "L  sequence  R" 
and 

by:  "L  list  R" 

The  strings  L  and  R  are  duplicated  and  later  used  in  the  application  of   the 

algorithm  to  both  'sequence'  and  'list'. 

The  semicolon  is  used  as  a  sequencing  mechanism;  execution  of 
'sequence'  may  only  follow  'item': 
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Replace:  "L  item;  sequence  R" 

by:  "L  item  V(sl)M 
and 

by:  MP(sl)  sequence  R"   [init:   si  <-  0] 

When  the  algorithm  is  later  applied  to  'item',  V(sl)  comprises  R;  when  applied 
to  'sequence'  L  is  P(sl). 

Colons  denote  permission  for  concurrent  execution  (the  sharing  of  up 
to  n  resources): 

Replace:   "L  n: (list)  RM 

by:   "P(s2)  L  list  R  V(s2)M     [init:   s2  <-  n] 

When  a  procedure  identifier  is  nested  within  several  of  these  constructions, 

the  order  in  which  operations  are  concatenated  to  the  strings  L  and  R  ensures 

that  the  synchronization  specified  by  more  deeply  nested  constructions  is 

applied  first. 

Brackets  ("["  and  "]")  specify  "burst  execution"  and  permit  concurrent 
execution  to  be  synchronized  with  other  coordination  schemes: 

Replace:  "L  [list]  R" 

by:  "PP(c,  s,  L)  list  W(c,  s,  R)" 

[init:  s  <-  1,  c  <-  0] 

where  PP  and  W  are  defined  below: 


PROCEDURE  PP  (COUNTER  c;  SEMAPHORE  s;  PROCEDURE  synch); 
BEGIN 
P(8)J 

c  :-  c  +  1; 
IF  c-1  THEN  synch; 
V(s) 
END; 
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PROCEDURE  W  (COUNTER  c;  SEMAPHORE  s;  PROCEDURE  synch); 
BEGIN 
P(s); 

c  :-  c  -  1 ; 
IF  c-0  THEN  synch; 
V(s) 
END; 

The  PP  and  VV  operations  implement  the  simultaneous  execution  synchronization. 

Parsing  is  complete  when  only  routine  names  remain: 

Replace:  "L  routine_id  R" 
by :        BEGIN 
L 

body  of  routine_id 
R 
END 

This  algorithm  must  constrain  each  routine  name  to  appear  exactly  once 
in  a  given  Path  expression.  This  restriction  may  be  removed  if  repeated  names 
are  treated  as  further  nesting  of  synchronization  constraints. 
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APPENDIX  D 

PROGRAMMING  EXAMPLES 


D.l   Printer  Example 

The  following  problem  is  taken  from  [Habermann,  76]  : 


A  group  of  processes  pl,p2,...pn  (n>»4)  share  three  line  printers 
LP1,  LP2,  and  LP3.  In  order  not  to  mix  output  lines  from  different 
processes,  a  process  must  reserve  a  line  printer  before  using  it.  A 
variable  is  attached  to  each  printer  which  specifies  the  index  of 
the  process  currently  using  the  line  printer  or  zero  if  the  line 
printer  is  free.  A  lineprinter  control  process,  LPC ,  has  an  output 
buffer  with  the  capacity  of  one  printer  line.  Once  a  process 
succeeds  in  reserving  an  LP,  it  starts  interacting  with  the  LPC  of 
the  lineprinter  to  get  its  output  printed.  When  the  buffer  is  full, 
the  LPC  should  print  its  contents  and  notify  the  process  that  the 
buffer  is  empty.  Write  cooperating  programs  for  a  process  and  an  LPC 
and  the  program  reserving  and  releasing  a  line  printer. 


This  problem  may  be  broken  up  into  four  parts.  First,  there  should  be 
a  line  printer  control  process  which  has  two  functions:  allocate  actual  line 
printers  to  user  processes  and  deallocate  actual  line  printers  from  user 
processes.  These  functions  will  be  provided  by  the  'manager'.  Second,  there 
should  be  a  process  which  empties  a  line  printer  buffer  to  the  actual  line 
printer.  One  such  process  should  be  instantiated  for  each  line  printer.  A  spe- 
cial machine  dependent  process  called  a  'device  process'  will  be  assumed  to 
exist  to  perform  this  function.  Third,  there  should  be  an  interface  between 
the  user  process  and  the  operating  system  that  will  help  prevent  line  printer 
abuse.  This  'virtual  printer'  will  interact  with  the  'manager'  to  request  and 
release  actual  line  printers  and  with  the  line  printer  buffer  to  output  infor- 
mation for  the  user  process.  Finally,  the  user  process  will  generate  data  and 
have  it  printed  to  some  line  printer. 

The  following  code  is  a  skeletal  outline  of  how   the  various   system 
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components  would  be  declared  in  the  actual  program. 


TYPE 

buffer  =  OBJECT  . 


.  END;  (*buffer*) 


VAR 


manager  :  OBJECT  ...  END;  (*manager*) 
lpbuffers  :  ARRAY [1.. 3]  OF  buffer; 


PROCEDURE  initsyscomponents; 


TYPE 


virtualprlnter  "OBJECT  ...  END;  (*virtualprinter*) 


PROCESS  userl;  BEGIN  . 
PROCESS  user 2;  BEGIN  . 


.  END;  (*userl*) 
.  END;  (*user2*) 


PROCESS  usern;  BEGIN 


END;  (*usern*) 


DEVICE  PROCESS  lineprinter  (  VAR  localbuff 
BEGIN  ...  END;  (*lineprinter*) 


BEGIN 

lineprinter (lpbuffers [1] , . . . ) 
lineprinter (lpbuffers [2] , «  *  •  ) 
lineprinter (lpbuffers [3] , . . . ) 
userl;  user2;  ...  usern 

END;   (*initsyscoraponents*) 


buffer;. . . ) ; 


The  'manager'  will  have  two  entry  operations.  The  function, 
'requestno',  reserves  an  actual  line  printer  for  a  user  process.  The  pro- 
cedure, 'releaseno',  returns  an  actual  line  printer  to  the  free  pool  of  line 
printers.  'Requestno'  should  be  executed  mutually  exclusively,  and  'releaseno' 
should  be  executed  mutually  exclusively.  At  most  three  user  processes  should 
be  allowed  to  execute  the  'requestno'  function,  and  a  'releaseno'  should  not 
be  allowed  until  the  'requestno'  has  been  completed.  The  path 


PATH  3:(  1:  (requestno)  ;  1 : (releaseno)  )  END; 
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specifies  these  constraints  completely.  The  variable  which  determines  which 
process  is  running  on  which  printer  is  declared  as 

processusingprinter  -  ARRAY [1.. 3]  OF  processnumber ; 

where  processusingprinter [i]  tells  which  process  is  running  on  the  ith 
printer.  Finally,  all  printers  should  be  initialized  to  the  idle  state.  This 
is  acconplished  by: 


FOR  i  :=  1  TO  3  DO 

processusingprinter [i]  :»  0; 


The  following  program  segment  performs  the  requested  duties. 
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VAR 

manager  :  OBJECT 

PATH  3:  (  1: (requestno)  ;  1: (releaseno)  )  END; 

VAR 

processusingprinter  :  ARRAY[1..3]  OF  processnumber 

ENTRY  FUNCTION  requestno  ( 

i  :  processnumber   )  :  INTEGER; 

VAR 

j  :  INTEGER;   reserved  :  BOOLEAN; 

BEGIN 

j  :=  1;  reserved  :=  true; 
WHILE  reserved  DO 

IF  processusingprinter [j]  *  0 
THEN  BEGIN 

processusingprinter [j]  :»  i; 
reserved  :=  false 
END 

ELSE  j  :=  j+1; 
reqestno  :=  j 
END;   (*requestno*) 

ENTRY  PROCEDURE  release  (i  :  INTEGER); 

BEGIN 

processusingprinter[i]  :*  0 
END;   (*releaseno*) 

INIT; 

VAR 

i  :  INTEGER; 

BEGIN 

FOR  i  :»  1  TO  3  DO 

processusingprinter [i]  :=  0 
END; 
END;   (*manager*) 


Each  user  process  needs  a  'virtualprinter'  that  will  interface  with 
the  'manager'  and  the  actual  line  printer.  A  user  may:  'request'  that  one  of 
three  line  printers  be  reserved  for  him,  'release'  his  dedicated  line  printer, 
or  'print'  Information  out  to  his  dedicated  printer.  A  user  process  may  only 
'request'  a  line  printer  if  no  printer  had  been  previously  allocated  to  it-  A 
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user  proceas  may  'release'  only  its  dedicated  printer.  Finally,  a  user  process 
may  only  'print'  if  it  has  a  dedicated  line  printer.  These  conditions  are 
specified  by  the  object,  'virtualprinter',  declared  below. 

TYPE 

virtualprinter  -  OBJECT 

PATH  release  ,  request  ,  print  END; 

VAR 

i  :  0.  .3 

ENTRY  PROCEDURE  request (  j  :  processnumber) ; 

BEGIN 

IF  i  -  0  THEN  i  :«  manager. requestno( j ) 
END; 

ENTRY  PROCEDURE  release; 

BEGIN 

IF   i   >   0  THEN   manager,  releaseno(i) 

END; 

ENTRY  PROCEDURE  print  (VAR  x:line;  j rprocessnumber) ; 

BEGIN 

IF   i  »  0  THEN   i    :■  manager. requestno(j ) ; 

lpbuffers[i].fill(x) 
END; 

INIT; 

BEGIN 

1  :-  0 

END; 
END; 

DEVICE  PROCESS  lineprinter  (  VAR  localbuff  :  buffer;...); 

VAR 

outline  :  line; 

BEGIN 

REPEAT 

localbuff .empty (out line) ; 
<print  outline  to  line  printer> 
UNTIL  false 
END; 
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The  device  process,  'lineprlnter',  is  the  machine  dependent  process 
that  takes  a  line  from  the  user  defined  buffer,  'localbuff,  and  outputs  it  to 
the  line  printer.  The  user  defined  type,  'buffer',  is  an  object  which  has  been 
declared  earlier.  The  circular  buffer  example  presented  below  in  Section  D.2 
might  be  easily  adapted  for  this  purpose.  'Buffer'  is  the  same  user  defined 
type  that  appeared  in  the  'print'  procedure  in  'virtualprinter' .  Notice  that 
in  both  cases,  no  information  is  used  about  the  buffer's  internal  structure. 
Therefore,  'buffer'  could  be  modified  extensively,  as  long  as  'empty'  and 
'fill'  are  the  entry  operations,  without  forcing  the  programmer  to  examine  the 
rest  of  his  program.  This  illustrates  the  high  degree  of  program  modularity 
attainable  in  Path  Pascal.  The  continuation  dots  in  the  process  heading  indi- 
cate that  some  machine  dependent  features  might  go  here  (i.e.,  parameters 
specifying  the  line  printer  priority  and  interrupt  vector  address). 

A  simple  example  of  how  a  user  program  might  be  declared  utilizing  a 
virtual  printer  is: 

PROCESS  userl; 

VAR 

lp  :  virtualprinter; 

computebuf fer  :  line; 
BEGIN 

lp  .request (1 ) ; 

REPEAT 

confutation  filling  computebuf  fer 
lp. print (computebuf fer, 1) 

UNTIL  no  more  computations; 

lp .release 
END; 

D.2    Circular  Buffer  Example  1. 

This  example  is  taken  from  an  earlier  paper  on  path  expressions  [Camp- 
bell  and  Habermann, 74]   for  purposes  of  comparison.  It  was  used  as  the  major 
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example  In  the  section  on  encapsulation. 


1  TYPE 

2  buffer  -  OBJECT 

3  PATH  5  :  (  I:  (fill)  ;  1:  (empty)  )  END; 

4  TYPE 

5  buffsize  -  0. .4; 

6  inbuff  -  ARRAY  [buffsize]  of  CHAR; 

7  nextspot  -  OBJECT 

8  PATH  inpointer  ,  outpointer  END; 

9  VAR 

10  inp,outp  :  buffsize; 

11  ENTRY  PROCEDURE  inpointer (VAR  x  :  buffsize); 

12  BEGIN 

13  x  :=  (  inp  +  1  )  MOD  5; 

14  inp  :»  x 

15  END; 

16  ENTRY  FUNCTION  outpointer  :  buffsize; 

1 7  BEGIN 

18  outp  :»  (  outp  +  1  )  MOD  5; 

19  outpointer  :»  outp 

20  END; 

21  INIT; 

22  BEGIN 

23  inp  :e  0;  outp  :■  0 

24  END; 

25  END;  (*nextspot*) 

26  VAR 

27  buf  :  inbuff; 

28  pointers  :  nextspot; 

29  ENTRY  PROCEDURE  fill  (  in char  :  CHAR  ); 

30  VAR 

31  x  :  buffsize; 

32  BEGIN 

33  pointers. inpointer(x) ; 

34  buf [x]  :*  inchar 

35  END;  (*fill*) 

36  ENTRY  FUNCTION  empty  :  CHAR; 

37  VAR 

38  x  :  buffsize; 

39  BEGIN 

40  x  :=  pointers. outpointer; 

41  empty  :-  buf  [x] 

42  END;   (*empty*) 

43  END;  (*buffer*) 


This  example  illustrates  circular  buffering  using  five  buffers.  The 
path  in  line  3  states  that  5  'fill'  operations  might  be  attempted  before  one 
'empty'  operation,  but  no  'empty'  operation  may  begin  until  at   least   one 
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'fill'  has  been  completed.  Unlike  the  original  example,  the  number  of  path 
expressions  has  been  reduced  at  the  expense  of  making  the  operation  'fill' 
mutually  exclusive  and  making  the  operation  'empty'  mutually  exclusive. 
Processes  invoking  the  'fill'  and  'empty'  routines  must  know  which  buffer  they 
should  access.  This  information  is  provided  by  the  nested  object,  'nextspot'. 
Only  one  process  at  a  time  should  be  able  to  access  either  of  the  buffer 
pointers  ('inp'  and  'outp'),  but  one  process  may  access  the  'inp'  pointer 
while  another  process  is  accessing  the  'outp'  pointer.  These  synchronization 
constraints  are  imposed  by  the  path  expression  in  line  8.  Note,  an  alternative 
scheme  might  have  been  to  declare  two  separate  variables  to  represent  the 
buffer  pointers.  Lines  21-24  show  how  it  is  possible  to  initialize  object 
variables  at  block  entry  time.  Lines  33  and  40  show  the  notation  required  to 
access  object  variables. 
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D.3   Circular    Buffer    Exaiqple    2. 

PROGRAM   EX1 (INPUT, OUTPUT); 
TYPE 

BUFFER-OBJECT 

PATH   5: (1: (FILL); 1:  (EMPTY))   END; 
TYPE 

BUFINDX-0. .4; 

INBUFF-ARRAY[BUFINDX]  OF  CHAR; 
VAR 

INPTR,OUTPTR:BUFINDX; 
BUF:INBUFF; 
ENTRY  PROCEDURE  FILL (INCHAR: CHAR ) ; 
BEGIN 

INPTR:=(INPTR+1)  MOD  5; 
BUF[INPTR] : -INCHAR; 
END;(*FILL*) 
ENTRY  FUNCTION  EMPTY: CHAR; 
BEGIN 

OUTPTR:«(OUTPTR+l)  MOD  5; 
EMPTY :-BUF[OUTPTR] ; 
END;(*EMPTY*) 
INIT; 
BEGIN 

INPTR : -0 ;OUTPTR : -0 ; 
END;(*INIT*) 
END;(*BUFFER*) 
VAR 

CIRCULAR: BUFFER; 
CH1,CH2:CHAR; 
BEGIN  (*MAIN  PROGRAM  STARTS  HERE*) 
CIRCULAR. FILL (CHI); 
CH2: -CIRCULAR. EMPTY; 
END.  (*END  OF  MAIN  PROGRAM*) 
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D.4       Circular  Buffer  Exanple   3. 

PROGRAM  BUFV2(INPUT,OUTPUT); 

CONST 

NUMBUFFERS-5; 

TYPE 
RINGBUF=OBJECT 

PATH  SPOOL, UNSPOOL  END; 

TYPE 

BUFINDX=0. .4; 
BUF=OBJECT 

PATH  1: (PUT; GET)  END; 

VAR  CH-.CHAR; 

ENTRY  PROCEDURE  PUT (C : CHAR); 

BEGIN 

CH:=C;  mJ.x 

END-(*END  OF  ENTRY  PROCEDURE  PUT*) 
ENTRY  PROCEDURE  GET (VAR  C:CHAR); 
BEGIN 

C:=CH; 
END;(*END  OF  ENTRY  PROCEDURE  GET*) 
END;  (*END  OF  OBJECT  BUF*) 

POINTER=OBJECT 

PATH  1:  (NEXTPTR)  END; 

VAR 

P:BUFINDX; 
ENTRY  FUNCTION  NEXTPTR: BUF INDX; 

BEGIN 

NEXTPTR:=P; 

P-=(P+1)  MOD  NUMBUFFERS; 
END;(*END  OF  ENTRY  FUNCTION  NEXTPTR*) 
INIT; 

BEGIN 
P:=0; 

END;(*END  OF  INIT  OF  OBJECT  POINTER*) 

END;(*END  OF  OBJECT  POINTER*) 

VAR 

HEAD, TAIL :POINTER; 

BUFFER : ARRAY [BUFINDX]  OF  BUF; 

ENTRY  PROCEDURE  SPOOL (C : CHAR) ; 

BEGIN 

BUFFER [HEAD. NEXTPTR] .PUT (C) ; 

END; 

ENTRY  PROCEDURE  UNSPOOL (VAR  C:CHAR); 

BEGIN 

BUFFER[TAIL. NEXTPTR]. GET(C); 
END;(*END   OF   ENTRY   PROCEDURE   UNSPOOL*) 
END;(*END   OF  OBJECT   RINGBUF*) 

BEGIN     (*MAIN    PROGRAM   STARTS    HERE*) 
END. 
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D.5   Teletype  Input/Output. 

PROGRAM  MINIOSVl(INPUT, OUTPUT); 
CONST 

LINEBUFSIZE-160; 

READBUFSIZE-5; 

BS-#010;  (*BACKSPACE  OR  CONTROL  H*) 

CR-#015;  (CARRIAGE  RETURN*) 

ESC-0033;  (*ESCAPE*) 
TYPE 

READPTRTYPE-O. .READBUFSIZE; 
LINEPTRTYPE-O- .LINEBUFSIZE; 
READBUFTYPE-ARRAY[1.. READBUFSIZE]  OF  CHAR; 
LINEBUFTYPE-ARRAYfi.. LINEBUFSIZE]  OF  CHAR; 
PROSIDTYPE-INTEGER;  (*PROCESS  ID  TYPE*) 
TELEIDTYPE-INTEGER;  (*TELETYPE  ID  TYPE*) 
BITS-SET  OF  0. .15;  (*BITS  IS  USED  AS  DEVICE 

STATUS /COMMAND  WORD*) 
(*OBJECT  DEFINITIONS  COMES  IN  HERE*) 
OBJOFTELE-OBJECT 

PATH  1:  (INTO;OUT),l:  (OPEN;CLOSE)  END; 

(*ENTRY  PROCEDURE  INTO  IS  FOR  TELETYPE  INPUT*) 

(*ENTRY  PROCEDURE  OUT  IS  FOR  TELETYPE  OUTPUT*) 

(*ENTRY  PROCEDURE  OPEN  IS  FOR  TELETYPE  RESERVING*) 

(*ENTRY  PROCEDURE  CLOSE  IS  FOR  TELETYPE  RELEASING*) 

(*LOCAL  OBJECT  DIFINITION  OF  OBJOFTELE*) 
TYPE 

OBJOFPROMPTOBJECT 

PATH  DONEPROMPT;STARTGET  END; 


ENTRY  PROCEDURE  DONEPROMPT; 
BEGIN 


END;  (*END  OF  ENTRY  PROCEDURE  DONEPROMPT*) 


ENTRY  PROCEDURE  STARTGET ; 
BEGIN 

END;  (*END  OF  ENTRY  PROCEDURE  STARTGET*) 
END;  (*END  OF  OBJECT  OBJOFPROMPT*) 


VAR 

READBUFFER : READBUFTYPE; 

LINEBUFFER:LINEBUFTYPE; 

TELEUSER:PROSIDTYPE; 

READ I N , ECHOOUT : READPTRT YPE ; 
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EDITIN : LINEPTRT YPE ; 
RESET: BOOLEAN; 
PROMPTS YNC : OB JOFPROMPT ; 
INOBJ: OBJECT 

PATH  5: (GETSSYNC; ECHOSYNC)  END; 

(*ENTRY  PROC  GETSSYNC  READS  ONE  CHARACTER 

WHEN  IT'S  INSTANTIATED*) 
(*ENTRY  PROC  ECHOSYNC  ECHOS  ONE  CHARACTER  WHEN 
IT'S  INSTANTIATED*) 


PROCEDURE  EDIT(VAR  EDITIN:LINEPTRTYPE;CH:CHAR) ; 
BEGIN 

IF  ORD(CH)=BS  THEN 

IF  (EDITIN>(LINEBUFSIZE-1))  THEN 

EDITIN :=(LINEBUFSIZE+EDITIN-1)  MOD 

LINEBUFSIZE 
(*BACK  PTR  EDITIN  BY  1  *) 
ELSE 

IF  (ORD(CH)=ESC)  THEN 

EDITIN: =LINEBUFSIZE-1 
ELSE 
BEGIN 

EDITIN := (ED ITIN+1)  MOD  LINEBUFSIZE; 
LINEBUFFER [EDITIN+1 ] : =CH ; 
END; 
END;  (*END  OF  PROCEDURE  EDIT*) 


ENTRY  PROCEDURE  GETSSYNC (VAR  READIN  : 

READPTRTYPE); 
BEGIN 

READIN :=(READIN+1)  MOD  READBUFSIZE; 
END;  (*END  OF  ENTRY  PROCEDURE  GETSSYNC*) 


ENTRY  PROCEDURE,  ECHOSYNC  ( 

VAR  ECHOOUT, EDITIN: READPTRTYPE); 
BEGIN 

ECHOOUT :«(ECHOOUT+l)  MOD  READBUFSIZE; 
IF  NOT  RESET  THEN 

EDIT(EDITIN,READBUFFER[ECHOOUT+l] ); 
END;  (*END  OF  ENTRY  PROCEDURE  ECHOSYNC*) 


END;  (*END  OF  OBJECT  INOBJ*) 


FETCHOBJ:OBJECT 

PATH  MOVE; FETCH  END; 
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(*ENTRY  PROCEDURE  MOVE  PUTS  LINEBUFFER  TO 

EDITBUFFER*) 
(*ENTRY  PROCEDURE  FETCH  GETS  LINEBUFFER  FROM 

EDITBUFFER*) 
ENTRY  PROCEDURE  MOVE; 
BEGIN 
END;  (*END  OF  ENTRY  PROCEDURE  MOVE*) 


ENTRY  PROCEDURE  FETCH (VAR  BUF:LINEBUFTYPE) ; 
BEGIN 

BUF: -LINEBUFFER; 
END;  (*END  OF  ENTRY  PROCEDURE  FETCH*) 

END;  (*END  OF  OBJECT  FETCHOBJ*) 


(*PROCESSES  AND  PROCEDURES  DEFINITIONS  OF  OBJECTTELE 
START  HERE*) 


INTERRUPT  PROCESS  GETS [PRIORITY-4; VECTOR-#60] ; 
VAR 

KBS [#177560] :BITS; 
KBB  [#177562]: CHAR; 
BEGIN 

PROMPT SYNC. ST ARTGET;  (*WAIT  UNTIL  THE  PROMPT  IS 

PRINTED*) 
REPEAT 

INOBJ.GETSSYNC(READIN); 
KBS:  =  [0,6]  ; 
DO  10; 

KBS:-KBS-[6];     (*DISABLE  READER   INTERRUPT*) 
READBUFFER [READIN+1 ] : -KBB ; 
UNTIL  RESET; 
END;     (*   END  OF   PROCESS   GETS*) 


INTERRUPT   PROCESS   ECHO [PRIORITY-4; VECTOR-64] ; 

VAR 

PTS [#177564] :BITS; 

PTB  [#177566] :CHAR; 

BEGIN 

REPEAT 

INOBJ . ECHOS YNC (ECHOOUT , EDITIN ) ; 

PTS:-[6]  ; 

PTB: -READBUFFER [ECHOOUT+1] ; 

DOIO; 

PTS:-PTS-[6];     (*DISABLE  PRINTER   INTERRUPT*) 
UNTIL   ORD (READBUFFER [ECHOOUT+1 ] ) -CR ; 
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RESET: -TRUE; 

WHILE  (READIN>ECHOOUT)  DO 

INOB J. ECHOS YNC (ECHOOUT , EDITIN ) ; 
FETCHOBJ.MOVE; 
END;  (*END  OF  PROCESS  ECHO*) 


INTERRUPT  PROCESS  PROMPT  [PRIORITY-4  ;VECTOR-#64]  ; 
VAR 

PTS [#177564] :BITS; 

PTB [#177566] :CHAR; 
BEGIN 

PTS: =[6];  (*ENABLE  PRINTER  INTERRUPT*) 

PTB:='?';  (*PRINT  A  PROMPT  '?'*) 

DOIO;  (*ENTER  WAIT  STATE  UNTIL  10  IS  DONE*) 

PTS:=PTS-[6];  (*DISABLE  PRINTER  INTERRUPT*) 

PROMPT S YNC. DONEPROMPT; 
END;  (*END  OF  PROCESS  PROMPT*) 


INTERRUPT  PROCESS  DOPRINT [PRI0RITY=4; VECTOR»#64] 

(BUF:LINEBUFTYPE); 
VAR 

I: INTEGER; 

PTS [#177564] :BITS;  (*PRINTER  STATUS  WORD*) 
PTB  [#177566] :CHAR;  (*PRINTER  BUFFER  WORD*) 
BEGIN 
I:-0; 
REPEAT 

I: =1+1; 
PTS:  =  [6]  ; 
PTB:=BUF[I]; 

DOIO;  (*ENTER  WAIT  STATE  UNTIL  10  IS  DONE*) 
PTS:=PTS-[6];  (*DISABLE  PRINTER  INTERRUPT*) 
UNTIL  ((I>=LINESIZE)  OR  (BUF  [I]  =CR)  ); 
END;  (*END  OF  PROCESS  DOPRINT*) 


ENTRY  PROCEDURE  OPEN (ID : PROS IDTYPE; VAR  I:TELEIDTYPE); 
BEGIN 

TELEUSER:=ID; 
END;  (*END  OF  ENTRY  PROCEDURE  OPEN*) 


ENTRY  PROCEDURE  CLOSE (ID:PROSIDTYPE;I :TELEIDTYPE)  ; 
BEGIN 

TELEUSER:-0; 
END;  (*END  OF  ENTRY  PROCEDURE  CLOSE*) 
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ENTRY  PROCEDURE  INTO (ID: PROS  IDT YPE;I :TELEIDTYPE; 

VAR  BUF:LINEBUFTYPE); 
BEGIN 

RESET: -FALSE; 

EDITIN:»LINEBUFSIZE-1;  (*SET  PTR  TO  THE  TAIL 

OF  RING  BUFFER*) 
READIN:«READBUFSIZE-1;  (*SAME  AS  ABOVE*) 
ECHOOUT:-READIN; 

PROMPT;  (*PRINT  OUT  A  PROMPT  '?'  *) 
GETS;  (*START  READING  ACTION*) 
ECHO;  (*START  ECHOING  PROCESS*) 
FETCHOBJ.FETCH(BUF);  (*PUT  ONE  LINE  OF 
CHARACTERS  INTO  BUF*) 
END;  (*END  OF  ENTRY  PROCEDURE  INTO*) 


ENTRY  PROCEDURE  OUT (ID: PROS IDTYPE; I : TELETYPE; 

BUF:LINEBUFTYPE); 
BEGIN 

DOPRINT; 
END;  (*END  OF  ENTRY  PROCEDURE  OUT*) 


END;  (*END  OF  OBJECT  OBJOFTELE*) 

(*MAIN  PROGRAM  STARTS  HERE*) 

VAR 

TELETYPE : OBJOFTELE ; 
BUF.-LINEBUFTYPE; 
PROS ID: PROS IDTYPE; 

TELEID:TELEIDTYPE;  (*STORE  TELETYPE  NUMBER, IF  MORE 

THAN  ONE  TELETYPE*) 
BEGIN  (*MAIN  PROGRAM  STARTS  HERE*) 
PROSID:=l;  (*ID  OF  THIS  PROCESS*) 
TELETYPE.OPEN(PROSID,TELEID);  (*OPEN  TELETYPE*, 

RESERVE  IT*) 
TELETYPE. INTO (PROSIS ,TELEID, BUF);  (*READ  IN  ONE 

LINE*) 
TELETYPE.OUT(PROSID,TELEID,BUF);  (*PRINT  OUT  ONE 

LINE*) 
TELETYPE. CLOSE  (PROS ID, TELEID);  (*RETURN  TELETYPE 

//TELEID  BACK*) 
END.  (*END  OF  MAIN  PROGRAM*) 
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APPENDIX  E 

EXTENDED  P-CODE 

E. 1   Modifications  to  P-Code 

The  Path  Pascal  compiler  is  written  in  Pascal  P4  and  can  be  compiled 
by  the  Pascal  P4  compiler  into  P-Code.  Pascal  P4  programs  may  be  compiled  by 
the  Path  Pascal  compiler  into  a  modified  P-Code.  The  modified  P-Code  differs 
from  the  original  by  the  inclusion  of  comment  cards  which  mark  the  beginning 
of  procedure  bodies  of  code.  The  comment  cards  are  used  to  provide  a  primi- 
tive debuggin  facility  in  the  Path  Pascal  interpreter  and  can  be  removed  to 
obtain  P-Code  which  will  execute  on  a  standard  P-code  interpreter.  Comment 
cards  do  not  affect  the  sequencing  or  numbering  of  P-code  instructions  and 
appear  as: 

*  procedurename 

with  '*'  appearing  in  column  1  and  'procedurename'  being  a  string  of  ten  char- 
acters . 

E.2  P-Code  Extensions 

The  following  extensions  to  P-Code  are  used  by  the  Path  Pascal  com- 
piler to  produce  code  for  the  extensions  to  Pascal  P4: 


PST  P,  Q  Create  a  stack,  heap  and  process  descriptor  record  (PDR) 
for  a  new  process.  The  instruction  behaves  in  a  similar 
manner  to  MST.  P  is  the  difference  level  between  the  calling 
procedure  and  called  process,  and  Q  is  the  size  of  the  stack 
required  for  the  new  process.  Storage  is  obtained  for  the 
stack  and  heap  from  the  heap  of  the  calling  procedure.  Note 
that  parameters  for  processes  must  be  copied  into  the  initial 
activation  record  of  the  new  process. 
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SPU  P,  Q  Activate  a  new  process.  Similar  to  CUP.  P  is  the 
number  of  locations  for  parameters,  Q  is  the  entry  point  of 
the  process.  The  PDR  for  the  new  process  is  updated  with  the 
entry  point  as  the  value  of  its  program  counter  and  the  PDR  is 
placed  on  the  ready  list  of  processes.  A  count  of  the  number 
of  sons  of  this  process  is  initialized. 

RTP  Process  completion.  Similar  to  RET.  Wait  for  the  completion  of 
any  processes  created  as  sons  to  this  process.  Sons  are 
processes  created  from  process  declarations  within  the  block 
of  this  process.  Return  PDR  storage.  (Garbage  collection 
could  be  done  if  required). 

CUP  Call  procedure  or  function.  This  instruction  has  been  modi- 
fied to  initialize  a  count  of  its  sons. 

RET  Return  from  a  procedure  or  function.  This  instruction  has 
been  modified  so  that  a  procedure  or  function  will  wait  for 
the  completion  of  any  processes  created  as  sons  before  return- 
ing. 

CSP  The  following  special  procedures  can  be  invoked  using  the  CSP 
instruction. 

ISM  Initialize  the  semaphore  whose  address  is  on  the  top  of  the 
stack  to  the  value  stored  in  the  top  minus  one  of  the  stack. 

VOP  Perform  a  V  operation  on  the  semaphore  whose  address  is  on  the 
stack. 

POP  Perform  a  P  operation  on  the  semaphore  whose  address  is  on  the 
stack. 

TIM     Push  the  system  clock  time  on  the  stack. 

DEL  Delay  the  current  process  by  the  time  given  on  the  stack  (  * 
1000  ). 

SIO  Store  an  interrupt  vector  for  this  process  at  the  absolute 
address  loaded  on  top  of  the  stack,  and  change  the  priority  of 
this  process  to  the  value  found  on  top  minus  one  of  the  stack. 

DIO  Suspend  this  process  while  I/O  occurs.  Load  the  interrupt 
vector  of  this  process  with  the  address  of  the  P-Code  instruc- 
tion following  DIO. 

The  ready  queue  and  semaphore  process  queues  are  maintained  in  order 

of   the  priority  of  processes,  processes  with  the  same  priority  are  maintained 

in  first  in,  first  out  order. 
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E.3  Absolute  Addresses 

Absolute  addresses  may  be  produced  by  the  Path  Pascal  compiler  for  the 
instructions : 

LDO,  SRO  and  LAO. 

These  addresses  appear  in  the  P-Code  as  negative  values  except  for  the  inter- 
rupt process  vector  address.  The  Path  Pascal  interpreter  currently  will  not 
accept  absolute  addresses  in  their  negative  format,  and  the  CSP  procedures  SIO 
and  DIO  are  ignored. 

E.4  Activation  Records  for  Path  Pascal  programs 

The  activation  record  for  a  Path  Pascal  program  includes  a  block  mark 
which  is  6  stack  words  long.  The  additional  words  are  used  only  by  the 
extended  instructions.  The  block  mark  is  used  in  the  following  manner  by  the 
Path  Pascal  interpreter: 

location       use 

6  Number  of  sons 

5  Return  address 

4  Check  on  storage  space  (Old  EP) 

3  Dynamic  Linkage  (Old  MP) 

2  Static  Linkage 

1  Function  value 
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APPENDIX  F 

A  SUMMARY  OF  PASCAL  P4 


1.  The  procedures  NEW,  MARK,  and  RELEASE  are  used  in  Pascal  P  to  manipulate 
heap  storage  instead  of  the  procedures  NEW  and  DISPOSE.  MARK  takes  an 
integer  parameter  and  assigns  that  integer  the  current  heap  address. 
RELEASE  takes  an  integer  parameter  which  has  presumably  been  previously  set 
by  MARK  and  returns  all  of  the  heap  storage  from  the  current  heap  address 
to  the  address  of  the  parameter.  Thus  the  storage  assigned  to  a  dynamically 
allocated  variable  can  be  released  by  calling  MARK  before  the  allocation 
and  RELEASE  afterward. 

2.  Only  four  files  may  be  used,  INPUT,  OUTPUT,  PRR,  and  PRD.  These  files  are 
all  text  files.  PRD  is  an  input  file  only,  PRR  is  an  output  file  only. 

3.  Procedures  and  functions  used  as  actual  parameters  to  a  procedure  or  func- 
tion invocation  are  evaluated  prior  to  the  invocation. 

4.  Procedures  and  functions  cannot  be  used  as  formal  parameters. 

5.  The  type  ALPHA  is  not  defined. 

6.  Literal  character  strings  have  a  maximum  length  of  10  characters. 

7.  Variant  records  must  include  the  declaration  of  a  variable  for  the  tag 
field. 
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